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SUMMARY OF THE CLAIMED SUBJECT MATTER: 

The subject matter of the claims on appeal concerns a medical system 
architecture wherein the devices for processing the examination images are 
fashioned as an RIS client for the exchange of text messages as well as for 
displaying an RIS client window and for the setup of RIS interaction masks and are 
connected via a network connection of the devices to an RIS server for the 
communication with the RIS client on the devices. The RIS server communicates 
with the RIS client on the modality, with the RIS client being made available in 
desktop-integrated form at the operator console of the modalities. This ensues in 
addition to the known DICOM communication. A network interface can be used for 
this purpose (network card with TCP/IP address), or a second interface can be 
installed. By realizing the RIS client on arbitrary console computers, for example as 
an RIS window, the RIS function can be operated from the same keyboard without a 
change in location on the part of user (p.4, 1.8-23). 

Figure 1 shows the system architecture of a hospital network by way of 
example. The modalities 1 through 4 serve for the acquisition of medical images; 
these can, for example, be a CT unit 1 for computed tomography, an MR unit 2 for 
magnetic resonance imaging, a DSA unit 3 for digital subtraction angiography and an 
X-ray unit 4 for digital radiography 4 as image-generating systems (p.7, 1. 5-9). 
Operator consoles 5 through 8 (workstations) of the modalities are connected to 
these modalities, the acquired medical images being capable of being processed 
and locally stored therewith. Patient data belonging to the images can also be 
entered (P.7, 1.13-18). 



The operator consoles 5 through 8 are connected to a communication 
network 9 as a LAN/WAN backbone for distributing the generated images and for 
communication. Thus, for example, the images generated in the modalities 1 
through 4 and the images that are further-processed in the operator consoles 5 
through 8 can be stored in central image storage and image archiving system 10 or 
can be forwarded to other workstations (p. 7, 1.13-18). 

Further viewing workstations represented nu a workstation 1 1 are connected 
to the communication network 9 as diagnostics consoles that have local image 
memories. For example, such a viewing workstation 11 is a very fast mini computer 
on the basis of one or more fast processors (p. 7, 1.19-22). The images that are 
acquired and deposited in the image archiving system 10 can be subsequently called 
in the viewing workstation 1 1 for diagnosis and can be deposited in the local image 
memory, from which they can be immediately available to the diagnostician working 
at the viewing workstation 1 1 (p7. 1.22- p9., I.2). 

Further, servers 12, for example patient data servers (PDS), file servers, 
program servers and/or EPR servers, are connected to the communication network 9 
(p.8, I.34). 

The image and data exchange via the communication network 9 ensues 
according to the DICOM standard, an industry standard for the transmission of 
images and further medical information between computers, so that a digital 
communication between diagnosis and therapy devices of different manufacturers is 
possible (p.8, 1. 5-8). A network interface 13 via which the internal communication 
network 9 is connected to a global data network, for example the world wide web, 



can be connected to the communication network 9, so that the standardized data 
can be exchanged with different networks world-wide (p. 8, I. 8-12). 

Inventively, an RIS server 14 is connected to the communication network 9, 
the operator consoles 5 through 8 communicating therewith with the communication 
network via TCP/IP protocols (p.8, 1.13-15). 

Figure 2 shows a monitor 15 of a console or backup console computer, for 
example the operator console 5 of the CT unit 1 (p.8, 1.16-17). The RIS client is 
connected to the RIS server via a network connection 16 of the operator console 5, 
but also can communicate with other DICOM-standardized and/or HL7-standardized 
RIS, HIS and PACS servers 12 by TCP/IP protocol via the internal communication 
network 9, for example an HIS server for the hospital information system, an EPR 
server or various PACS serves such as diagnosis consoles, image archive, web 
image distribution server, etc. (p.8, 17-23). The RIS client uses standard application 
protocols like DICOM, HL7 but also http in order to reach Internet/Intranet servers 
(p.8, 1.23-24). 

An image processing window 18, for example the "examination task card", is 
reproduced on the user interface 17 with a number of CT exposures, next to which 
icons 19 for triggering commands are arranged in a known way (p. 9, 1.1-3). 

Such task cards are known from PCT Application WO 00/31673. User 
requests or tasks that are to be viewed as an activity of a workflow and that can be 
advantageously utilized particularly in image post-processing and diagnosis given all 
imaging methods of medical technology are capable of being selected in a simple 
and fast way with said task cards (p.9, I.4-8). A number of tasks or activities can be 
processed in parallel and arbitrarily called. The user interface is thereby subdivided 



into regions, whereby overlays with information of the user request ensue in a control 
region, fields in the manner of card tabs 23 are arranged at the edge of the user 
interface, different user requests being respectively allocated to the card tabs 23, 
and the currently called, current, visible user request being recognizably marked on 
the card tab 23. The card tabs 23 arranged at the edge according to this card tab 
concept see to a clear division. A medical workflow is realized therewith (p.9, 1.8-15). 

When inputs are to be made from the CT operator console 5 as an RIS client 
into the RIS server 14, or when data from the RIS server 14 are to be transmitted 
into the RIS client (the operator console 5 of the CT unit 1 ), then an RIS client 
window 21, for example the picture screen mask for patient registration, is opened 
on the monitor 15 by clicking on an RIS icon 20 with the mouse (p.9, 1.16-20). All 
RIS inputs by MTRA or physician now ensue via the keyboard of the console 
computer without requiring the operator to go to an extra RIS client terminal. The 
operator can also unproblematically switch between the image processing window 
18 and the RIS client window 21 (p.9, 1.21-24). 

Figure 3 shows an alternative solution of the desktop integration wherein the 
RIS client is realized as a separate task card. The user interface of the RIS client 
appears here when the user clicks on the RIS cardfile card tab 24 at the right edge of 
the picture screen, so that the RIS client window 21 for patient registration known 
from Figure 2 again opens up as task card 22. The subsequent work with the RIS 
client ensues exactly as in the case of the solution in Figure 2 (p. 10, 1.1-6). 

Figure 4 shows a possible workflow scenario of an inventive apparatus. It 
describes the clinical workflow with the various work steps and the use of the 
software packets of the various systems such as, for example, the RIS or the 
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modality P. 10, 1. 7-9). The application software employed, the respective software 
packet/function of the various systems in the sequence of the clinical workflow is 
shown at the left side, and the data flow is shown at the right side. The data flow is a 
listing of the data that are utilized by the software packets during the various work 
steps (p.10, 1.9-13). 

First, the application software of the various systems is described in the 
sequence of the clinical workflow (left column): 

a) First, the patient registration ensues with the RIS and the patient data 
are automatically transferred into the DICOM work list. 

b) After reception of the DICOM work list, these patient data are 
transmitted in the modality via the work list. Given the selection of a 
patient, the data and the examination program are loaded according to 
the question and the examination is started. 

c) The examination by the modality ensues. 

d) After the end of the examination, the transfer of the examination data to 
the RIS ensues via DICOM. The confirmation and documentation of 
the examination ensue here. 

e) Next, the data for billing are forwarded to the HIS. 

f) The examination data proceed from the modality for further diagnosis, 
for example at a workstation (p. 10, 1.14 - p.1 1 , 1. 6). 

The data flow of the various work steps utilized by the software packets is 
described in the sequence of the clinical workflow (right column): 

a) The patient's primary data and the examination request are acquired or 
fetched. 



-6- 



b) The examination particulars are input. 

c) The exposure . data and the consumable are acquired during the 
examination, for example number of studies, series and images, type 
of sequences, radiation protection data (kV, mAs, sec, Gy). 

d) The data are taken by the RIS (p.11, 1.7-14). 

The simplification of the operation on a single computer with a single 
keyboard is the directly visible and immediately available benefit for MTRAs and 
physicians that follow from the desktop integration of the RIS client on the console 
computer of a modality (p. 11, 1.15-18). 

The communication of the RIS server with the RIS client is explained in 
greater detail on the basis of Figure 5. An RIS server application 25 communicates 
with an RIS client application 26 that runs on a machine 27. A modality 28 that can 
comprise a modality-RIS mediator application 29 and modality applications 30 
through 32 can also run on the same machine 27 (p. 13, 1.1-5). 

The modality-RIS mediator application 29 inserts a button 33 for starting the 
RIS client application 26 into the main menu of the modality 28 (p. 13, I.6-7). 

The modality applications 30 through 32 have an extension mechanism 34 
through 36 in order to enable an activation for other applications (for example, 30 
through 32 or 26) and expands a modality-RIS mediator application 29 therewith 
(p.13, 1.9-10). 

The modality applications 30 through 32 start an RIS client application 26 with 
the button 33 from the main menu of the modality 28(p.13, 1.1 1-12). 
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The RIS client application 26 communicates with the modality-RIS mediator 
applications 29, for example via an OLE protocol 37, and queries its modality 
application extensions 34 through 36 (p. 13, 1.13-15). 

The modality-RIS mediator application 29 returns references to its current 
extensions 34 through 36 via the OLE protocol 37 and what is referred to as a 
"magic cookie" 38 through 40 for each extension. The RIS client application 26 
inserts these into its user interface (Ul) for subsequent activation (p.13, 1.16-19). 

When the Ul activation of a specific modality application extension 34 through 
36 ensues from the RIS client application 26, this is forwarded to the modality-RIS 
mediator application 29 together with the patient information selected in the RIS 
client 26 and the "magic cookie" 38 through 40 (p.13, I.20-23). Via another transport 
41 , said application 29 attempts to get the necessary image data and forwards them 
to the respective extensions 34 through 36 that are referenced by the "magic cookie" 
38 through 40. The respective extension 34 through 36, finally, transfers the request 
to the respective modality application 30 through 32 (p.13, I.23 -p. 14, I.3). 

The request is predetermined for the modality application 30 through 32 by 
the extensions 34 through 36 and the modality application 30 through 32 can no 
longer distinguish who ultimately initiated the activation, i.e. a specific mechanism is 
not required for the RIS client per application, (p. 14, 1.4-7) 

The modality application 30 through 32 can subsequently load the image data 
for the diagnosis, (p. 14, I.8-9) 

This method can be arbitrarily repeated dynamically at the run time for further 
modality applications 30 through 32 that can likewise be dynamically activated from 
the RIS client application 26. It is thus assured that new and existing applications 



can be automatically connected to the RIS client application 26 and integrated into 
each modality 28. Further, modality applications 30 through 32 and RIS client 
application 26 can be modified independently of one another (p. 14, 1.10-15). 

The RIS client application 26 usually runs (but not necessarily) on the same 
machine 27 as the modality 28 and communicates with the information system of the 
RIS server application 25 via a different transport mechanism in order to connect the 
patient information of the information system with the modality applications 30 
through 32 of a modality 37 (p.14, 1.16-20). 

The extensions of the RIS client application 26, the "magic cookies" 38 
through 40, make user interface plugins available in the RIS client in order to activate 
the modality applications 30 through 32 as though the activation had come from 
another modality application. Here, the modality-RIS mediator application functions 
as link between RIS client and modality application (p.14, 1.21 -p.15, 1. 2). 

The modality-RIS mediator application is a mediator or link. In this case, it 
adapts between modality applications — via their extensions to the mediator, since 
this is constructed like a modality applications — and the RIS client (P.15, 1. 3-5). 
ISSUES TO BE REVIEWED ON APPEAL: 

The issue to be reviewed on appeal is whether the subject matter of claims 1- 
1 1 would have been obvious to a person of ordinary skill in the field of designing 
computerized medical system architecture based on the teachings of United States 
Patent No. 6,359,628 (Buytaert) and United States Patent No. 6,578,002 (Derzay et 
al.), under the provisions of 35 U.S.C. §1 03(a). 



ARGUMENT: 

Rejection of Claims 1-11 Under 35 U.S.C. §103(a) As Being Unpatentable Over 
Buytaert In view of Derzay et al. 

The basic purpose of the system disclosed in the Buytaert reference is to pool 
patient data with images on a monitor on a DLR system, which can make use of a 
radiology information system (RIS). The Buytaert reference, however, does not 
provide any details or teachings as to how the RIS interacts with the overall system, 
and specifically does not provide any teachings as to how, or even if, the RIS 
interacts with a user via display or user interface at a work station. The Buytaert 
reference is simply directed to exchanging text messages and displaying RIS client 
windows at a work station. 

The acquisition system disclosed in the Buytaert reference makes use of an 
RIS in order to add demographic patient information to acquired images (read from 
RIS, write to image). The system disclosed in the Buytaert reference does not 
display the images for the purposes of making a diagnostic analysis thereof, but only 
for making a cursory check of the information content thereof and, as needed, to 
insert the aforementioned demographic patient information. 

By contrast, the medical system architecture disclosed and claimed in the 
claims on appeal, as set forth in claim 1, makes use of an RIS mediator, which 
allows all workstations for all different imaging modalities (CT, MR, ultrasound, 
conventional x-ray, nuclear medicine, digital angiography, etc.) as well as multi- 
modality workstations, to communicate with each other. The use of a DLR system is 
possible in the architecture disclosed and claimed in the present application, 
however, this is but one example of one possible modality (for conventional x-ray 
systems). 



For explaining the operation of the architecture disclosed and claimed in the 
present application, and for understanding the differences thereof with regard to the 
system described in the Buytaert reference, it should first be noted that an RIS 
contains only references to stored data. The actual data are stored in an archiving 
system, such as a PACS. A computer program (such as the commercially available 
Syngo program) must be activated by the RIS client via the RIS mediator, in order to 
load the referenced data from a PACS archive. For this purpose, a search for the 
data must be initiated, and the data, when found, then must be transferred from the 
archive to the work station at which the processor and interface are present. This is 
done under the control of the RIS mediator. Only after the requested (referenced) 
data are available at the processor does the RIS mediator start the application 
(program) selected by the RIS client, and provide the (now locally present) data to 
the program in order to display the necessary images. The architecture disclosed 
and claimed in the present application, therefore, enables a user to implement, at a 
single workstation (processor) the work steps selected by the RIS client and to 
generate the necessary results. As soon as the user has achieved a satisfactory 
result, the user can mark the selected task as being completed in the RIS client. 

Only because all operating tools (RIS, DICOM and post-processing software) 
are present at a single workstation can work list jobs be read that provide the 
necessary data, and be processed to completion without the user having to change 
workstations, and without the user having to be trained to use a number of different 
systems. 

As noted above, even though the Buytaert reference mentions the display of 
RIS client windows, the only teaching in the Buytaert reference that can be found as 



to any use that is made thereof is for the purpose of adding the aforementioned 
demographic patient information to the acquired images. There is no teaching or 
suggestion in the Buytaert reference to conduct any type of image processing or 
analysis, nor is there any teaching or suggestion that all necessary steps for 
conducting such processing and analysis can be conducted via a single workstation 
(processor), by making use of an RIS mediator and an RIS server with the processor 
being programmed as an RIS client. 

As explained in the present specification as originally filed in the description 
relating to Figure 5, beginning at the top of page 13, the RIS client software is started 
at the workstation, without the necessity of the use of a program developed at the 
software platform itself. By means of the RIS mediator, the RIS client is able to 
determine all programs that are available at the workstation at the start-up time, and 
also is able to obtain graphical symbols (icons) for each program or application, so 
that an optical presentation of all of the necessary icons in the user interface of the 
RIS client is possible. Not only is the optical integration of symbols enabled by the 
RIS mediator, but also the RIS mediator allows the RIS system to start these 
applications or programs. Moreover, after a program or application has been 
started, the RIS mediator also allows the RIS client via the RIS server, to transmit 
the necessary references to the stored data that are needed to retrieve the stored 
data from an archiving location. 

The Derzay et al. reference describes no more than a "remote services 
concept" for imaging modalities, in which an application or program can be started 
via an icon. The icons used in the Derzay et al. reference, however, do not permit 
the aforementioned functions of the RIS mediator, RIS client and RIS server to be 
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accomplished, and therefore a person of ordinary skill in the field of devising medical 
system architectures using an RIS has no reason to consult a reference such as the 
Derzay et al. reference. 

The aforementioned functions performed by the RIS mediator, the RIS client 
and the RIS server are exclusive to the use of an RIS, and therefore the Derzay et 
al. reference provides a person of ordinary skill in the field of medical system 
architecture design with no teachings in that area. The Derzay et al. reference 
therefore provides no more than generalized concepts relating to exchanging data 
between remote devices, and provides no guidance for embodying those teachings 
in, nor even any indication that those teachings can be used in, an RIS. 

The Federal Circuit stated in In re Lee 227 F.3d 1338, 61 U.S.P.Q. 2d 1430 
(Fed. Cir. 2002): 

"The factual inquiry whether to combine references must be thorough 
and searching. ...It must be based on objective evidence of record. 
This precedent has been reinforced in myriad decisions, and cannot be 
dispensed with." 

Similarly, quoting C.R. Bard, Inc. v. M3 Systems, Inc., 157 F.3d 1340, 1352, 

48 U.S.P.Q. 2d 1225, 1232 (Fed. Cir. 1998), the Federal Circuit in Brown & 

Williamson Tobacco Court v. Philip Morris, Inc., 229 F.3d 1120, 1124-1125, 56 

U.S.P.Q. 2d 1456, 1459 (Fed. Cir. 2000) stated: 

[A] showing of a suggestion, teaching or motivation to combine the 
prior art references is an 'essential component of an obviousness 
holding 1 . 

In In re Dembiczak, 175 F.3d 994,999, 50 U.S.P.Q. 2d 1614, 1617 (Fed. Cir. 
1999) the Federal Circuit stated: 

Our case law makes clear that the best defense against the subtle but 
powerful attraction of a hindsight-based obviousness analysis is 
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rigorous application of the requirement for a showing of the teaching or 
motivation to combine prior art references. 



Consistently, in In re Rouffet, 149 F.3d 1350, 1359, 47 U.S.P.Q. 2d 1453, 

1459 (Fed. Cir. 1998), the Federal Circuit stated: 

[E]ven when the level of skill in the art is high, the Board must identify 
specifically the principle, known to one of ordinary skill in the art, that 
suggests the claimed combination. In other words, the Board must 
explain the reasons one of ordinary skill in the art would have been 
motivated to select the references and to combine them to render the 
claimed invention obvious. 

In Winner International Royalty Corp. v. Wang, 200 F.3d 1340, 1348-1349, 53 

U.S.P.Q. 2d 1580, 1586 (Fed. Cir. 2000), the Federal Circuit stated: 

Although a reference need not expressly teach that the disclosure 
contained therein should be combined with another, ... the showing of 
combinability, in whatever form, must nevertheless be clear and 
particular. 

Lastly, in Crown Operations International, Ltd. v. Solutia, Inc., 289 F.3d 1367, 

1376, 62 U.S.P.Q. 2d 1917 (Fed. Cir. 2002), the Federal Circuit stated: 

There must be a teaching or suggestion within the prior art, within the 
nature of the problem to be solved, or within the general knowledge of 
a person of ordinary skill in the field of the invention, to look to 
particular sources, to select particular elements, and to combine them 
as combined by the inventor. 

Moreover, the Derzay et al. reference does not provide any of the "missing" 
teachings discussed above with regard to the Buytaert reference, and thus even if 
the Buytaert reference were modified in accordance with the teachings of Derzay et 
al., the subject matter of claims 1-11 still would not result. Claims 1-11, therefore 
would not have been obvious to a person of ordinary skill in the field of medical 
architecture design, under the provisions of 35 U.S.C. §1 03(a) based on the 
teachings of Buytaert and Derzay et al. 
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CONCLUSION: 

For the above reasons, Appellants respectfully submit the Examiner is in error 
in law and in fact in rejecting claims 1-11 of the application. Reversal of the rejection 
is proper, and the same is respectfully requested. 

A check for the fee required by 37 C.F.R. §1 .1 7(f) in the amount of $500.00 is 
submitted herewith. 

Submitted by, 

(Rea. 28.982) 

SCHIFF, HARDIN LLP 
CUSTOMER NO. 26574 

Patent Department 
6600 Sears Tower 
233 South Wacker Drive 
Chicago, Illinois 60606 
Telephone: 312/258-5790 
Attorneys for Appellant(s). 

CERTIFICATE OF MAILING 

I hereby certify this correspondence is being deposited with the United States 
Postal Service as First Class mail in an envelope addressed to: Commissioner for 
Patents, P.O. Box 1450, Alexandria, Virginia 22313-1450 on January 25. 2006 . 

STEVEN H. NOLL 
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CLAIMS APPENDIX 

1 . A medical system architecture comprising: 
a modality for acquiring examination images; 

a processor connected to said modality for processing said examination 
images; 

a user interface for said processor; 

a transmission system connected to said processor for transmitting said 
examination images to a location remote from said processor; 

a memory connected to said transmission system for storing said examination 
images; 

an RIS server; and 

said processor being programmed as an RIS client with an RIS mediator for 
exchanging text messages and for displaying an RIS client window at 
said interface and for creating RIS interaction masks at said interface, 
and producing a network connection to said RIS server for 
communicating with said RIS client to allow transfer of images from 
said remote location to said processor via said RIS server for general 
purpose processing and analysis of said images at said processor, 
using said RIS client window and said RIS interaction masks. 

2. A medical system architecture as claimed in claim 1 wherein said 
processor comprises RIS client software for processing said examination images. 
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3. A medical system architecture as claimed in claim 2 wherein said 
processor includes general operating software, and wherein said RIS client software 
is integrated into said general operating software. 

4. A medical system architecture as claimed in claim 2 wherein said 
processor includes a user interface, and wherein said RIS client software is 
integrated into said user interface. 

5. A medical system architecture as claimed in claim 2 wherein said 
processor includes platform software, and wherein said RIS client software is 
integrated into said platform software. 

6. A medical system architecture as claimed in claim 1 wherein said 
processor has a monitor, and wherein said processor is programmed for displaying 
said examination images on said monitor and for mixing said RIS client window into 
a display on said monitor next to said examination images. 

7. A medical system architecture as claimed in claim 6 wherein said 
processor displays an icon on said monitor with which said RIS client window can be 
opened. 

8. A medical system architecture as claimed in claim 1 wherein said 
processor includes a user interface, and wherein said RIS client has a task card 
allocated thereto on said user interface. 

9. A medical system architecture as claimed in claim 1 wherein a 
workflow associated with acquiring and processing and processing said examination 
images is controlled by said RIS client for automatic information transmission. 
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10. A medical system architecture as claimed in claim 1 wherein said 
processor functions as a control console for said modality, and wherein said RIS 
client supplies data for analyzing said examination images. 

11. A medical system architecture as claimed in claim 1 wherein said RIS 
client comprises a statistics module for evaluating data associated with said 
examination images. 
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